REMARKS 

The above amendment is made in response to the Office Action mailed April 2, 
2004. Claims 1-9 are pending in the present application and stand rejected. Claims 1-6 
and 8-9 have been amended. Claim 7 has been cancelled. It is believed that no new matter 
has been added. The Examiner's reconsideration is respectfully requested in view of the 
above amendment and the following remarks. 

Substitute Specification 

A substitute specification, which is attached hereto, is submitted as required by the 
Office Action. The substitute specification corrects minor grammatical errors, and 
includes no new matter. 

Amendments to the Abstract 

The abstract of the disclosure has been corrected above as required by the Office 
Action. The amendments to the abstract of the disclosure correct minor grammatical 
errors, and include no new matter. Withdrawal of the objection to the abstract of the 
disclosure is respectfully requested. 

Rule 105 Requirement for hiformation 

Under Rule 105, the Office Action has required Applicants to provide information 
regarding "LISP/6A." The acronym "LISP" stands for "LiMing hitegrated Services 
Platform." The official "6A" product website is provided at http://www.iswitch.eom/.cn . 
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All information which is known and readily available to the parties from which it 
was requested has been provided. 

Objections to the Drawings 

The Office Action objects to the drawings under Rule 83(a), arguing that the 
process of transforming a device request into XML must be shown in the drawings or the 
feature canceled from the claims. We respectfully traverse. 

Figure 1 shows a two-shade box in the DAL. The two-shade box (labeled protocol 
adaptation/content adaptation) transforms a device request into an XML request, as 
essentially claimed in claim L Further, Figure 7 shows a step of "transcoding XML XSL." 
It is respectfully submitted that the term "transcoding" is a well-known to those skilled in 
the art of pervasive computing for transforming between various data formats. 

Withdrawal of the objections to the drawings is respectfiiUy requested. 

Objections to the Claims 

Claims 1 and 2 have been amended to correct minor informalities. Withdrawal of 
the objection to the claims is respectfiiUy requested. 

Claim Rejections - 35 U.S.C. § 1 12. first paragraph 
Claims 1 and 2 stand rejected under 35 U.S.C. § 1 12, first paragraph. The 
Examiner argues that "[tjhere is no description in the applicant's specification providing 
any hint as to how 'user/device/service' is defined." Applicants disagree. The use of three 
profiles (user, device and service) are shown in Figure 1 and in the specification on page 
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1 1, lines 24-25. Nevertheless, further clarification is provided in the supplemental 
specification on page 3, lines 18-19. 

Claim 1 stands rejected under 35 U.S. C. § 1 12, first paragraph. The Office Action 
argues that the "specification. . .provides no guidance as what format a device request is in 
or how a request is transformed [into XML]." Applicants respectfully traverse. On page 
3, lines 3-8. the DAL is stated to comprise a "[c]ommon transcoding component" and a 
"[d]evice dependent component." The common transcoding component is "for 
transformation between different kinds of data formats." The device dependent component 
is for "transforming between (whatever kind of data format/transporting protocol for that 
particular device) and (XML over HTTP). The term "transcoding" is well-known to those 
skilled in the art of pervasive computing for transforming among various data formats for 
different devices due to, for example, the size of the screen and user interfaces of the 
device. It allows one skilled in the art to create the pluggable service delivery platform of 
the claimed invention without concern for a particular device format. Further, as shown in 
Figure 1, data (in whatever format is in) is transferred fi"om the device to the device- 
platform interface using a transport protocol (e.g., HTTP, WAP, PSTN). Such transport 
protocols are well-known to those skilled in the art to include a plurality of tags. One 
skilled in the art would be knowledgeable in transforming such tags into XML. It is 
respectfully submitted that the above disclosure would enable one skilled in the art to 
practice the claimed invention. 

Claim 7 stands rejected under 35 U.S.C. § 1 12, first paragraph. Claim 7 has been 
cancelled. 
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Withdrawal of the rejection to claims 1 and 7 under 35 U.S.C. §112, first paragraph 
is respectfully requested. 

Claim Rejections ~ 35 U.S.C. § 112. second paragraph 

Claims 1-9 stand rejected under 35 U.S.C. § 1 12, second paragraph. Rejection 
number 40 on page 8 of paper no. 4 is traversed. The term "profile manager" as claimed in 
claim 5 was properly introduced in claim 3. With regard to the remaining rejections, the 
claims have been amended accordingly. Withdrawal of the rejections to claims 1-9 under 
35 U.S.C. § 1 12, second paragraph is respectfully requested. 

Claim Rejections - 35 U.S.C. § 102 

Claims 1-9 stand rejected under 35 U.S.C. § 102(e) as being anticipated by Gao 
(U.S. Patent No. 6,581,094). The rejection is respectfully traversed. 

The Office Action simply recites the entire original claim 1, ending with a generic 
citation to Gao . Without analysis of each and every limitation of the claim, Applicants are 
effectively left to guess as to where in Gao the Office Action is arguing anticipates the 
claim. Applicants respectfully submit that the Office Action must provide a proper citation 
to Gao for each and every limitation of the claims. 

Nevertheless, after a review of a Gao, Applicants respectfully submit that Gao does 
not disclose each and every limitation of claim 1. 

Accordingly, claim 1 is believed to be patentably distinct over Gao. Dependent 
claims 2-8 are believed to be allowable for at least the reasons given for claim 1. 
Withdrawal of the rejection of 1-8 under 35 U.S.C. §102(e) is respectfully requested. 
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In view of the foregoing remarks, it is respectfully submitted that all the claims 
now pending in the application are in condition for allowance. Early and favorable 
reconsideration is respectfully requested. 



F. CHAU & ASSOCIATES, LLC 
1900 Hempstead Turnpike, Suite 501 
East Meadow, New York 1 1554 
Telephone: (516)357-0091 
Facsimile: (516)357-0092 



Respectfully submitted, 



By: 




Koon Hon Wong 
Reg. No. 48,459 
Attorney for Applicants 
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This invention relates to- a service delivery 
platform that supports many devices to access many 
services and more particularly, to a pluggable service 
delivery platform in which many devices and many services 
are pluggable. 

2 . Description of Related Art 

Nowadays there are a lot of pervasive computing 
devices such as handheld PCs, smartphone, mobile phone, 
screenphone, pager, fax machine, etc. They all have sort 
o# computing power and people wish to use these existing 
devices to access the network and do e-business. But 
there also exists challenges, since current network 
infrastructure is designed for PC. At the same time 
different services have different features. Under this 
environment, some effort is needed to connect a new 
device to the network, if while — after the backend system 
is changed, e.g., some new service is added, the 
application on the device must be changed (or added) ; 
similariy effort is needed to changed the logic of 
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backend services when new devices roll out. With the 
rapid development of network computing, there is a need 
forp€ a pluggable service delivery platform that can 
support many devices and many services in a flexible and 
5 scalable way. 

Some companies have designed some platforms for 
supporting many devices to access many services, but 
these platforms are designed specifically for some 
devices and services and there is no flexible way to plug 
10 a new kind of device or a new type of service into the 
platform. 



SUMMMIY OF THE INVENTION 

The pluggable platform of the present invention can 
be used to overcome the shortcomings. of existing 

15 platforms. The platform can be used in e-business and 
support many kinds of devices to access many types of 
services, while at the same time, new devices or new 
services can be easily added to the platform. This is 
where "pluggable" comes from. 

20 The pluggable service delivery platform of the 

present invention comprises: 
- Device Abstraction Layer (DAL) 

It accepts the requests from devices and transforms 
them into XML and then sends them to the kernel of the 

25 platform. It also transforms the response XML documents 
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from the platform into a device specific format for 

presentation. It further comprises: 

(1) Common transcoding component, shared by all devices 
and used for trans forminq tranocoding between different 
kinds of data formats . 

(2) Device dependent component, transforming between 
(whatever kind of data f ormat/tranporting protocol for 
that particular device ) and (XML over HTTP) . 

- Service Abstraction Layer (SAL) 

It abstracts the common requirements from different 

services as a service profile. For each kind of service 

in some domain, a wrapper (adapter) is provided. The 
wrapper is used for transforming between (legacy data 
format/network protocol) and (XML/HTTP) . 

- Kernel Service Engine 

The functions provided by the platform kernel 
service engine include: 

- manage profiles of users, devices and services 
(i.e. , user/device/service) 

- synchronize/asynchronize service engine 

- interface with other platform components 

- transfer information between components within the 
platform using XML. 

The platform is "pluggable" in three aspects. 
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Firstly, it is pluggable in the sense that a new 
kind of device can be easily plugged into the platform so 
long as the device profile that describes the device 
capability is provided. 
5 Secondly, it is pluggable in the sense that a new 

type of service can be easily plugged into the platform 
so long as the service profile that describes the service 
feature is provided. 

Thirdly, it is pluggable in the sense that the 
10 components that constitute the platform are pluggable, so 
any one of the components can be replaced by third party 
products, so long as the latter-s- comply with a predefined 
interface, such as a Java Servlet and- r LDAP, 

The advantages of the platform of this invention 
15 over existing platforms are listed in Table 1. 

A local network company had the similar idea of a 
many-to-many platform called LISP/6A. The table below 
shows the differences and why the platform of the present 
invention is superior. 

20 
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TABLE 1 



Features 


LISP/6A 


This platform 


Transcoding 


No. Format has to be 
customized for each 
kind of device 


Yes. The same 
content can be 
adapted to 
different kind of 
PvC devices 


Scalability 


No 


Yes. With Network 
Dispatcher & Web 
Traffic Express & 
Distributed 
Application Tester 


Contents 

representation in 
platform 


Fixed segments with 
annotation 


Represented in XML, 
easy to be extended 


Support 

synchronized and 

asynchronized 

communication 


No 


Yes 


Flexibility for 
plug in new 
device 


No 


Yes 


Flexibility for 
plug in new 
service 


No 


Yes 


Component i zed 
parts within 
platform 


No 


Yes 



JP9-1999-0279US (8728-464) -5- 



These and other aspects, features and advantages of 
the present invention will be described or become 
apparent by the following detailed description of the 
preferred embodiments, which is to be read in connection 
5 with the accompanying drawings. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 shows a preferred embodiment of a pluggable 

service delivery platform, which focuses on components of 
a platform kernel - 
10 FIG. 2 shows the servlet (service engine) running on 

WebSphere (an IBM Web application server) . 

FIG. 3 shows the data flow between the service 
engine and the backend service (such as stock service) . 

FIG. 4 shows the device abstraction layer 
15 (device-platform interface) of the pluggable service 
delivery platform of Fig. 1. 

FIG. 5 shows the service abstraction layer 
(platform-service interface) of the pluggable service 
delivery platform of Fig. 1. 
20 FIG. 6 shows an implementation of the present 

invention using a ^WAP phone to access services through 

the platform. 

FIG. 7 shows the process of adding a new kind of 
device to the platform. 
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FIG. 8 shows the process of adding a new type of 
service to the platform. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 

5 It is to be understood that the exemplary system 

modules and method steps described herein may be 
implemented in various forms of hardware, software, 
firmware, special purpose processors, or a combination 
thereof. Preferably, the present invention is implemented 

10 in software as an application program tangibly embodied 
on one or more program storage devices. The application 
program may be executed by any machine, device or 
platform comprising suitable architecture. It is to be 
further understood that, because some of the constituent 

15 system modules and method steps depicted in the 
accompanying Figures are preferably implemented in 
software, the actual connections between the system 
components (or the process steps) may differ depending 
upon the manner in which the present invention is 

20 programmed. Given the teachings herein, one of ordinary 
skill in the related art will be able to contemplate 
these and similar implementations or configurations of 
the present invention. 

Before describing preferred embodiments in detail, 

25 the terms used in the present invention are first listed 
as follows: 
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TERMS USED : 

1. XML (extensible Markup Language): as it-^s name says, 
it is a kind of markup language endorsed by W3C (Web 
standard organization) , It is used to describe/define 

5 structured data and separate the data with presentation 
(compared with HTML which strongly combines data and the 
presentation) . The same set of data expressed by XML 

language can generate a different presentation (Markup 

Language) with a different style sheet language (XSL: 

10 extensible Stylesheet Language) . Since data represented 
in XML are highly structured, they are very suitable for 
automatically exchanging information between 

applications. The adoption of XML for exchange between 
different components, is the biggest characteristic of the 

15 invention. 

2. WAP (Wireless Application Protocol): a wireless 
communication protocol specifically designed for handheld 
devices (especially mobile phones.) . WAP is critical for 
mobile phones to access the information on the net just 

20 as a important PC using HTML/HTTP to access the 

Internet . 

3. Servlet: Java small service application, a special 
kind of Java class running on a Web server. It can accept 
the request from the Web (browser) , parse the parameters 

25 and execute the predefined logic (such data connection 
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with backend system) and generate a response and send ijt 
back to the browser. Since Java Servlets are written in 
Java they are cross platform (OS) and highly portable 
applications. Java servlet can dynamically generate 
5 different pages for different kinds, of devices such as 
HTML for PC, WML for WAP phone, etc. 

4. Trancoding: a kind of transformation technique which 
transforms the same set of data into different pages 
based on predefined criteria (such as. display resolution, 

10 color depth, multimedia support) . The technique further 
consists of many components, including an image 
transcoder (e.g. GIF -> JPEG, JPEG -> BMP, color -> grey 
-> black/white) and a— text transcoder (e.g. text 
abstraction, text -> audio) . Using a transcoding 

15 technique, one type of XML document can be transformed 
into another type of XML document and can further be 
transformed into some kind of presentation (e.g. HTML or 
WML) by style sheet language. 

5. Device gateway: the device gateway in the invention 
20 sits in the device abstraction layer, it can accept a 

request from a device over some sort of network protocol, 
transform it into XML over HTTP, then send it to the 
platform kernel. After getting the data from the b ackend 
system through the platform kernel, it then transforms. 
25 the page into a device readable page and sends, it to the 
device over the network that the device connects to. 
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6. Service adapter (wrapper) : the service adapter in the 
invention sits in the service abstraction layer, it 
transforms between the platform format 

(XML) /protocol (HTTP) and service specific 

5 format/protocol . 

The following paragraphs will illustrate in detail 
how to implement the invention. 

The pluggable service delivery platform shown in 
FIG. 1 comprises three parts, Device Abstraction Layer 

10 (DAL) , Service Abstraction Layer (SAL) and Kernel Service 
Engine. FIG. 1 focuses on components of a platform 
kernel. The detail of SAL and DAL will be illustrated in 
FIG. 4 and FIG. 5 respectively. As shown in FIG. 1, the 
platform kernel comprises a service engine 101, a runtime 

15 monitor 102, a profile manager 103 and auxiliary 
components 104 (such as a billing manager 104a, a 
security manager 104b, etc.) As shown in FIG. 1, XML is 
used within the platform as an interface language. XML is 
used widely in the platform to exchange information 

20 between different components in the platform. XML is also 
used in the DAL and SAL, such that — also information 
processed in the platform will be based on XML. For the 
service engine^ both a synchronized service engine and an 
asynchronized service engine are provided. For example, 

25 the synchronized service engine can be based on IBM 
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WebSphere which is a Web application server and has 
strong XML support. 

FIG. 2 shows how servlets are organized in 
WebSphere. As shown, servlets are built b uild on and 
5 managed by WebSphere (start, stop, add, delete) . A chain 
of servlets can be called when a request from the device 
is sent to the p latform, processed by the p latform, till 
responded with a page. The first servlet called, which is 
also the most important one, corresponds to a called URL. 

10 The servlet can — further then call other servlets which 
th e n form a servlet chain. As shown in FIG. 2, under 
WebSphere application server (Default Server) , there is a 
ServletEngine which is the base Servlet engine. Under 
Servlet Engine there are many directories, such as 

15 "def ault_app" , "admin", "examples", etc. Under some 
specific application, there have been some servlets that 
will be used. For example, under "def ault_app" , there are 
"Snoop" servlet, "hello" servlet, "ErrorReporter" 
servlet, etc. 

20 FIG. 3 shows the data chart and also the interaction 

between the service engine and the backend service (e.g. 

stock service) . 

The platform runtime monitor 102 is used to monitor 

the runtime status of platform. 
25 The profile manager 103 is used to manage a user 

profile, device profile and service profile. 
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The user profile can include items as^ user ID, user 
name, telephone number, etc. 

The device profile can include items as, device ID, 
vendor name, device type, display resolution, multimedia 
5 capability, corresponding XSL (which is used to present 
XML data on that specific device) . 

The service profile can include items as, service 
ID, service provider, operating time, start URL, etc. 

Besides the above components, the platform kernel 
10 can also include many auxiliary components, such as a 
device manager to manage device access, a service manager 
to manage service connection to the platform, an event 
manager to trigger some platform related event and send 
to user, a transaction manager, a billing manager, and a 
15 security manager. All the above components are pluggable 
and can be replaced by third party products. 

In FIGS. 1-3, the kernel parts of the platform are 
described in detail. These components are used to manage 
user/device/service profile information, provide a 
20 synchronized/asynchronized service engine, use XML to 
exchange information and carry transaction related 
information between different parts of the platform. As 
shown in FIG. 1, the platform kernel consists of three 

layersj_— a runtime layer, an admin layer and a 

25 development layer. Platform APIs are used to interact 
between layers. The runtime layer provides online 
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information access and control, the management layer 
provides service such as add/delete user/device/service 
information, and the development layer provides support 
for a new device/service. 
5 In FIG. 4 SAL will be described in detail. 

There are mainly two portions in FIG. 4. The first 
portion, on top of the dotted line, is what we call 
Control mode. The administrator can use the UI under this 
mode to install new services and configure the existing 

10 services . ' Both the control mode portion and run-time mode 

portion have a PnP (plug and play) manager. The 

enumeration is used to abstract the common features of 
different services, and differentiate them by different 
industrial. The second portion, under the dotted line, is 

15 what we call Run-time mode and has mainly three layers. 
The bottom layer is the enumeration. Specific industrial 
should have-s- its specific drivers which should obey the 
open service protocol. The middle layer is the Service 
Abstract Layer (SAL) . SAL abstracts, the common 

20 requirement of different services. The upper layer is the 
kernel of run-rime mode and is called run-time unit. It 
further comprises several important parts. The first one 
and the most important one is the PnP manager that 
corresponds to the PnP manager in the Control mode 

25 portion. It has an event listener to listen to events 
' cominqe offle from the service-platform interface. It 
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manaqes servco — a-e — managing the plugged services to the 
platform. Then there's the maintenance manager. It's used 
to manage the lifetime of a service like when it's opened 
and closed, when it will expire, etc. The third one is 
5 the resource manager. Then there is the security manager 
to manage the security in the platform to securely 
transfer messaged and documents. The total service design 
architecture is EVENT DRIVEN - and STATE BASED. The 
relationship between different layers is like this. The 

10 Service Abstract Layer enumerate (maintain) and 
administrate services and report events, to the run-time 
unit. It also works with the run-time unit to manage 
transactions, to make sure that several commands from one 
transaction will not be broken into pieces. The main 

15 event types include a New service event, an Update event, 
etc. All the events are related to service-platform 
interaction and platform operation. 

In FIG. 5 DAL will be described in detail. 

There are also two parts in FIG. 5. The one above 

20 the dashed line includes. Profile Generating Tools to 
generate a profile for some new device. The information 
will be saved in the registry and can be accessed by the 
profile manager of the administrator UI. The other part 
under the dashed line consists of a Device Abstract 

25 Layer, a Profile Manager, and Run-time managers. The 

run-time managers then include a Protocol manager, a 
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Connection manager, a Contents manager and an event 

manager. A common interface (Device Abstract Layer) is 
needed to define the common behavior of PvC devices. The 
devices may connect to the platform in different ways 
5 (e.g. LAN/WAN, PSTN, GSM/CDMA and CDPD) , so gateways are 

needed for each kind of connection. No matter how the 
device is connected to the platform, the devices' rich 
features, can be extended from this common base. And this 
common base is expressed in XML too. The profile managers 

10 servea ^ee — s e rved as the focal point between the p latform 
device administrator and the p latform run-time kernel. 
The features, of the device are- jrs- saved in the registry as 
(key, value) pairs. Protocol manager is used to decide 
whether to send the message through IP or HTTP protocol 

15 in the platform. Connection manager is used to manage the 
connect in a transaction, i.e. set up the connect when 
device request, or send the message when certain 
conditions meet. Contents manager is built upon the 
transcoding technique. It decides how to send out the 

20 message. It assembles QSsemblv the contents based on the 
devices' profile. Event manager generates, system events 
when a device contacts, the platform. (Certain profile 
header should be provided in the head of the message that 
the device sends.) . No matter how the device accesses the 

25 platform (through GSM, CDPD, PSTN, LAN or other ways), it 
is required to include a description of the device 
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(profile) in the header of the message it sends, to the 
platform when it is logged on. 

In the above paragraphs, a preferred embodiment of a 
pluggable platform according to the present invention is 
5 illustrated. The platform has the following advantages: 
no matter what kind of device the end users use they can 
always access the key information in a consistent and 
natural way and all the returned pages will fit well on 
that device. This also simplified the service connection 

10 process. For now, the service providers need only one 
reserved line to connect the service to the service 
delivery platform. 

FIG. 6 shows how a service can be hosted on the 
platform. To be specific, the process of using WAP phone 

15 to access the services through the platform is shown. 
Firstly, various WAP phones connect to the WAP gateway 
through GSM network and then data channels (PSTN 
connection or ISDN connection) . The information before 
WAP gateway is binary WML over WAP, while after the WAP 

20 gateway, it will be WML over HTTP. When a user uses the 
WAP phone, some URL has actually been selected, the 
request will be sent to a servlet that corresponds to the 
URL. The servlet will analyze the request parameter, call 
some service wrapper as required, then get data from 

25 background services. This kind of data connection is 
common to domain service and independent of the specific 
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service provider. After getting the data, the servlet 
will reorganize the data and generate a page (e.g. HTML 
or WML) . The page can be generated by transcoding means 
after retrieving the device style sheet (XSL) stored in 
5 device profile through LDAP call. 

FIG. 7 shows how to plug a new kind of device. When 
adding a new kind of device the system administrator can 
use the admin tools and select "Add New Device" item, 
then fill in a form to generate a device profile in the 

10 profile manager. Among the description, XSL is used to 
describe device capability. At the runtime, when the 
platform receives user requests, onfe^ one hand, it will 
generate XML data based on the return from service, and 
one the other hand, it will retrieve the device profile 

15 from the profile manager, then generate the final page 
layout based on the transcoding technique. 

FIG. 8 shows how to plug a new kind of service. When 
adding a new kind of service the system administrator can 
use the admin tools and select "Add New Service" item, 

20 then fill in a form to generate a service profile in the 
profile manager. At the runtime, when the user connects 
to the platform, only a dynamic service list that the 
user subscribes will be listed. 

Although illustrative embodiments of the present 

25 invention have been described herein with reference to 
the accompanying drawings, it is to be understood that 
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the present invention is not limited to those precise 
embodiments, and that various other changes and 
modifications may be affected therein by one skilled in 
the art without departing from the scope or spirit of the 
invention. All such changes and modifications are 
intended to be included within the scope of the invention 
as defined by the appended claims. 
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